1. Field of the Invention
The present invention relates generally to the field of device virtualization and, more specifically, to a centralized device virtualization layer for heterogeneous processing units.
2. Description of the Related Art
In a conventional computer system, a central processing unit (CPU) is capable of executing multiple operating systems (OSs). A software program known as a “hypervisor” is often used to coordinate the operations of the different OSs. The hypervisor manages input/output (I/O) access operations (accesses) transmitted from each OS to various hardware devices included in the computer system. These hardware devices may include memory modules, computer monitors, hard disk drives, and CD-ROM drives, among others. The hypervisor allows each of the OSs to access the hardware devices using a technique known as “device virtualization,” which may be used to create virtual instances of a hardware device. A hardware device may be virtualized via “software virtualization” and/or “hardware virtualization.”
When software (SW) virtualization is implemented, the hypervisor divides the resources of a hardware device into multiple “guest physical resources.” Each guest physical resource may then be assigned to a particular OS. The hypervisor advertises the guest physical resources to the OSs so that when an OS attempts to access the guest physical resources associated with a hardware device, the hypervisor may trap the access to ensure that the correct context is loaded on the hardware device before allowing that OS to access the hardware device.
When hardware (HW) virtualization is implemented, each hardware device advertises multiple instances of that HW device so that each instance is allocated the full amount of resources made available by the hardware device. Each OS is then assigned one of those instances. The hypervisor acts as an arbiter between the OSs by determining which OS may access a particular virtualized device. Since HW virtualization is implemented in hardware, the hypervisor may not be aware that a particular physical resource is being virtualized. Each HW virtualized device recognizes conflicts with other virtualized devices and resolves these conflicts (e.g., by restoring contexts or quiescing one or more of the virtualized instances of that device) before taking action on the physical resource.
SW virtualization and HW virtualization work well when a single processor executes multiple OSs on top of a single hypervisor. However, more diverse processor topologies that include multiple CPUs executing multiple OSs are less amenable to SW virtualization and/or HW virtualization. For example, a multi-CPU computer system may include several CPUs that are each connected to the same group of hardware devices. Some hardware devices cannot be virtualized in hardware or in software, thus, the computer system includes only one resource for that hardware device that cannot be shared by two CPUs. Implementing SW virtualization in a multi-CPU computer system is also problematic because bottlenecks can be created when an OS wants to access a SW virtualized hardware device that is being underutilized. Since the resources of the hardware devices are divided into guest physical resources, each OS can only utilize a portion of the total resources of the hardware device. When only one OS is attempting to access the hardware device, that OS may require more resources than are allocated by the guest physical resource. A resource bottleneck is created because resources of the hardware device are still available, but the OS cannot utilize these resources because they have been allocated to other guest physical resources.
Implementing HW virtualization in a multi-CPU computer system is also problematic because a virtualized device would need to be created for each OS running on each CPU. Implementing HW virtualization for each hardware device would significantly increase the resources advertised within the computer system and would force each hardware device to be virtualized for each OS, even though a particular OS may not need to utilize the resources provided by a particular hardware device.
Accordingly, there remains a need in the art for an improved technique for virtualizing hardware devices in a multi-CPU computer system.